All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Sudeep Holla <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
Subject: Re: [PATCH v6 37/37] firmware: arm_scmi: add dynamic scmi devices creation
Date: Mon, 15 Mar 2021 08:33:27 +0000	[thread overview]
Message-ID: <20210315083327.p6gculrdl3vlavhp@bogus> (raw)
In-Reply-To: <20210202221555.41167-38-cristian.marussi@arm.com>

Hi Cristian,

Sorry for the delay.

On Tue, Feb 02, 2021 at 10:15:55PM +0000, Cristian Marussi wrote:
> Having added the support for SCMI protocols as modules in order to let
> vendors extend the SCMI core with their own additions it seems odd to
> then force SCMI drivers built on top to use a static device table to
> declare their devices since this way any new SCMI drivers addition
> would need the core SCMI device table to be updated too.
>
> Remove the static core device table and let SCMI drivers to simply declare
> which device/protocol pair they need at initialization time: the core will
> then take care to generate such devices dynamically during platform
> initialization or at module loading time, as long as the requested
> underlying protocol is defined in the DT.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v4 --> v5
> - using klist instead of custom lists
> v3 --> v4
> - add a few comments
> ---
>  drivers/firmware/arm_scmi/bus.c    |  30 +++
>  drivers/firmware/arm_scmi/common.h |   5 +
>  drivers/firmware/arm_scmi/driver.c | 309 +++++++++++++++++++++++++----
>  3 files changed, 310 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 88e5057f4e85..88149a46e6d9 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -51,6 +51,31 @@ static int scmi_dev_match(struct device *dev, struct device_driver *drv)
>  	return 0;
>  }
>
> +static int scmi_match_by_id_table(struct device *dev, void *data)
> +{
> +	struct scmi_device *sdev = to_scmi_dev(dev);
> +	struct scmi_device_id *id_table = data;
> +
> +	return sdev->protocol_id == id_table->protocol_id &&
> +		!strcmp(sdev->name, id_table->name);
> +}
> +
> +struct scmi_device *scmi_find_child_dev(struct device *parent,
> +					int prot_id, const char *name)
> +{
> +	struct scmi_device_id id_table;
> +	struct device *dev;
> +
> +	id_table.protocol_id = prot_id;
> +	id_table.name = name;
> +
> +	dev = device_find_child(parent, &id_table, scmi_match_by_id_table);
> +	if (!dev)
> +		return NULL;
> +
> +	return to_scmi_dev(dev);
> +}
> +
>  const struct scmi_protocol *scmi_get_protocol(int protocol_id)
>  {
>  	const struct scmi_protocol *proto;
> @@ -114,6 +139,10 @@ int scmi_driver_register(struct scmi_driver *driver, struct module *owner,
>  {
>  	int retval;
>
> +	retval = scmi_request_protocol_device(driver->id_table);
> +	if (retval)
> +		return retval;
> +
>  	driver->driver.bus = &scmi_bus_type;
>  	driver->driver.name = driver->name;
>  	driver->driver.owner = owner;
> @@ -130,6 +159,7 @@ EXPORT_SYMBOL_GPL(scmi_driver_register);
>  void scmi_driver_unregister(struct scmi_driver *driver)
>  {
>  	driver_unregister(&driver->driver);
> +	scmi_unrequest_protocol_device(driver->id_table);
>  }
>  EXPORT_SYMBOL_GPL(scmi_driver_unregister);
>
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 1e2046c61d43..9a0519db4865 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -307,6 +307,11 @@ struct scmi_transport_ops {
>  	bool (*poll_done)(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer);
>  };
>
> +int scmi_request_protocol_device(const struct scmi_device_id *id_table);
> +void scmi_unrequest_protocol_device(const struct scmi_device_id *id_table);

Sorry for being pedantic, I don't like these names. I would prefer
something like scmi_protocol_device_{create,destroy/delete}_request.
The action the function does needs to be at the end of the function name.
Atleast that is something I follow. I haven't checked all the previous
patches, just this function made to look at both the name style and the
name itself.


> +struct scmi_device *scmi_find_child_dev(struct device *parent,
> +					int prot_id, const char *name);
> +

scmi_child_dev_find based on what I mentioned above. Please change all
other non-static functions even if I have not mentioned. Try to cover
all the new functions introduced in this series, existing ones we can
take up later.

>  /**
>   * struct scmi_desc - Description of SoC integration
>   *
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index dcdfd94b47f7..9fc979e3b16f 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -21,6 +21,7 @@
>  #include <linux/io.h>
>  #include <linux/kernel.h>
>  #include <linux/ktime.h>
> +#include <linux/list.h>
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> @@ -56,6 +57,14 @@ static DEFINE_MUTEX(scmi_list_mutex);
>  /* Track the unique id for the transfers for debug & profiling purpose */
>  static atomic_t transfer_last_id;
>
> +static DEFINE_IDR(scmi_requested_devices);
> +static DEFINE_MUTEX(scmi_requested_devices_mtx);
> +
> +struct scmi_requested_dev {
> +	const struct scmi_device_id *id_table;
> +	struct list_head node;
> +};
> +
>  /**
>   * struct scmi_xfers_info - Structure to manage transfer information
>   *
> @@ -113,6 +122,8 @@ struct scmi_protocol_instance {
>   * @protocols_mtx: A mutex to protect protocols instances initialization.
>   * @protocols_imp: List of protocols implemented, currently maximum of
>   *	MAX_PROTOCOLS_IMP elements allocated by the base protocol
> + * @active_protocols: IDR storing device_nodes for protocols actually defined
> + *		      in the DT and confirmed as implemented by fw.
>   * @notify_priv: Pointer to private data structure specific to notifications.
>   * @node: List head
>   * @users: Number of users of this instance
> @@ -130,6 +141,7 @@ struct scmi_info {
>  	/* Ensure mutual exclusive access to protocols instance array */
>  	struct mutex protocols_mtx;
>  	u8 *protocols_imp;
> +	struct idr active_protocols;
>  	void *notify_priv;
>  	struct list_head node;
>  	int users;
> @@ -936,6 +948,13 @@ static void scmi_devm_put_protocol(struct scmi_device *sdev, u8 protocol_id)
>  	WARN_ON(ret);
>  }
>
> +static inline
> +struct scmi_handle *scmi_handle_get_from_info(struct scmi_info *info)
> +{
> +	info->users++;

Doesn't it race with anything ? I have already forgotten how this is used
and in what context this gets called.

> +	return &info->handle;
> +}
> +
>  /**
>   * scmi_handle_get() - Get the SCMI handle for a device
>   *
> @@ -957,8 +976,7 @@ struct scmi_handle *scmi_handle_get(struct device *dev)
>  	list_for_each(p, &scmi_list) {
>  		info = list_entry(p, struct scmi_info, node);
>  		if (dev->parent == info->dev) {
> -			handle = &info->handle;
> -			info->users++;
> +			handle = scmi_handle_get_from_info(info);

Ah here it is. Any particular reasons for moving it to separate function ?

--
Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Sudeep Holla <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
Subject: Re: [PATCH v6 37/37] firmware: arm_scmi: add dynamic scmi devices creation
Date: Mon, 15 Mar 2021 08:33:27 +0000	[thread overview]
Message-ID: <20210315083327.p6gculrdl3vlavhp@bogus> (raw)
In-Reply-To: <20210202221555.41167-38-cristian.marussi@arm.com>

Hi Cristian,

Sorry for the delay.

On Tue, Feb 02, 2021 at 10:15:55PM +0000, Cristian Marussi wrote:
> Having added the support for SCMI protocols as modules in order to let
> vendors extend the SCMI core with their own additions it seems odd to
> then force SCMI drivers built on top to use a static device table to
> declare their devices since this way any new SCMI drivers addition
> would need the core SCMI device table to be updated too.
>
> Remove the static core device table and let SCMI drivers to simply declare
> which device/protocol pair they need at initialization time: the core will
> then take care to generate such devices dynamically during platform
> initialization or at module loading time, as long as the requested
> underlying protocol is defined in the DT.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v4 --> v5
> - using klist instead of custom lists
> v3 --> v4
> - add a few comments
> ---
>  drivers/firmware/arm_scmi/bus.c    |  30 +++
>  drivers/firmware/arm_scmi/common.h |   5 +
>  drivers/firmware/arm_scmi/driver.c | 309 +++++++++++++++++++++++++----
>  3 files changed, 310 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 88e5057f4e85..88149a46e6d9 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -51,6 +51,31 @@ static int scmi_dev_match(struct device *dev, struct device_driver *drv)
>  	return 0;
>  }
>
> +static int scmi_match_by_id_table(struct device *dev, void *data)
> +{
> +	struct scmi_device *sdev = to_scmi_dev(dev);
> +	struct scmi_device_id *id_table = data;
> +
> +	return sdev->protocol_id == id_table->protocol_id &&
> +		!strcmp(sdev->name, id_table->name);
> +}
> +
> +struct scmi_device *scmi_find_child_dev(struct device *parent,
> +					int prot_id, const char *name)
> +{
> +	struct scmi_device_id id_table;
> +	struct device *dev;
> +
> +	id_table.protocol_id = prot_id;
> +	id_table.name = name;
> +
> +	dev = device_find_child(parent, &id_table, scmi_match_by_id_table);
> +	if (!dev)
> +		return NULL;
> +
> +	return to_scmi_dev(dev);
> +}
> +
>  const struct scmi_protocol *scmi_get_protocol(int protocol_id)
>  {
>  	const struct scmi_protocol *proto;
> @@ -114,6 +139,10 @@ int scmi_driver_register(struct scmi_driver *driver, struct module *owner,
>  {
>  	int retval;
>
> +	retval = scmi_request_protocol_device(driver->id_table);
> +	if (retval)
> +		return retval;
> +
>  	driver->driver.bus = &scmi_bus_type;
>  	driver->driver.name = driver->name;
>  	driver->driver.owner = owner;
> @@ -130,6 +159,7 @@ EXPORT_SYMBOL_GPL(scmi_driver_register);
>  void scmi_driver_unregister(struct scmi_driver *driver)
>  {
>  	driver_unregister(&driver->driver);
> +	scmi_unrequest_protocol_device(driver->id_table);
>  }
>  EXPORT_SYMBOL_GPL(scmi_driver_unregister);
>
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 1e2046c61d43..9a0519db4865 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -307,6 +307,11 @@ struct scmi_transport_ops {
>  	bool (*poll_done)(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer);
>  };
>
> +int scmi_request_protocol_device(const struct scmi_device_id *id_table);
> +void scmi_unrequest_protocol_device(const struct scmi_device_id *id_table);

Sorry for being pedantic, I don't like these names. I would prefer
something like scmi_protocol_device_{create,destroy/delete}_request.
The action the function does needs to be at the end of the function name.
Atleast that is something I follow. I haven't checked all the previous
patches, just this function made to look at both the name style and the
name itself.


> +struct scmi_device *scmi_find_child_dev(struct device *parent,
> +					int prot_id, const char *name);
> +

scmi_child_dev_find based on what I mentioned above. Please change all
other non-static functions even if I have not mentioned. Try to cover
all the new functions introduced in this series, existing ones we can
take up later.

>  /**
>   * struct scmi_desc - Description of SoC integration
>   *
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index dcdfd94b47f7..9fc979e3b16f 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -21,6 +21,7 @@
>  #include <linux/io.h>
>  #include <linux/kernel.h>
>  #include <linux/ktime.h>
> +#include <linux/list.h>
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> @@ -56,6 +57,14 @@ static DEFINE_MUTEX(scmi_list_mutex);
>  /* Track the unique id for the transfers for debug & profiling purpose */
>  static atomic_t transfer_last_id;
>
> +static DEFINE_IDR(scmi_requested_devices);
> +static DEFINE_MUTEX(scmi_requested_devices_mtx);
> +
> +struct scmi_requested_dev {
> +	const struct scmi_device_id *id_table;
> +	struct list_head node;
> +};
> +
>  /**
>   * struct scmi_xfers_info - Structure to manage transfer information
>   *
> @@ -113,6 +122,8 @@ struct scmi_protocol_instance {
>   * @protocols_mtx: A mutex to protect protocols instances initialization.
>   * @protocols_imp: List of protocols implemented, currently maximum of
>   *	MAX_PROTOCOLS_IMP elements allocated by the base protocol
> + * @active_protocols: IDR storing device_nodes for protocols actually defined
> + *		      in the DT and confirmed as implemented by fw.
>   * @notify_priv: Pointer to private data structure specific to notifications.
>   * @node: List head
>   * @users: Number of users of this instance
> @@ -130,6 +141,7 @@ struct scmi_info {
>  	/* Ensure mutual exclusive access to protocols instance array */
>  	struct mutex protocols_mtx;
>  	u8 *protocols_imp;
> +	struct idr active_protocols;
>  	void *notify_priv;
>  	struct list_head node;
>  	int users;
> @@ -936,6 +948,13 @@ static void scmi_devm_put_protocol(struct scmi_device *sdev, u8 protocol_id)
>  	WARN_ON(ret);
>  }
>
> +static inline
> +struct scmi_handle *scmi_handle_get_from_info(struct scmi_info *info)
> +{
> +	info->users++;

Doesn't it race with anything ? I have already forgotten how this is used
and in what context this gets called.

> +	return &info->handle;
> +}
> +
>  /**
>   * scmi_handle_get() - Get the SCMI handle for a device
>   *
> @@ -957,8 +976,7 @@ struct scmi_handle *scmi_handle_get(struct device *dev)
>  	list_for_each(p, &scmi_list) {
>  		info = list_entry(p, struct scmi_info, node);
>  		if (dev->parent == info->dev) {
> -			handle = &info->handle;
> -			info->users++;
> +			handle = scmi_handle_get_from_info(info);

Ah here it is. Any particular reasons for moving it to separate function ?

--
Regards,
Sudeep

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

  reply	other threads:[~2021-03-15  8:34 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 22:15 [PATCH v6 0/37] SCMI vendor protocols and modularization Cristian Marussi
2021-02-02 22:15 ` 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 [this message]
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=20210315083327.p6gculrdl3vlavhp@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=cristian.marussi@arm.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=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.