All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Thara Gopinath <thara.gopinath@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com,
	lukasz.luba@arm.com, james.quinlan@broadcom.com,
	Jonathan.Cameron@Huawei.com, f.fainelli@gmail.com,
	etienne.carriere@linaro.org, vincent.guittot@linaro.org,
	souvik.chakravarty@arm.com
Subject: Re: [PATCH v4 37/37] firmware: arm_scmi: add dynamic scmi devices creation
Date: Fri, 8 Jan 2021 14:42:57 +0000	[thread overview]
Message-ID: <20210108144257.GD9138@e120937-lin> (raw)
In-Reply-To: <50434a02-0fe0-50f3-1529-51ab8a0cc1f3@linaro.org>

On Thu, Jan 07, 2021 at 09:28:07AM -0500, Thara Gopinath wrote:
> Hi Christian,
> 
> On 1/6/21 3:16 PM, 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>
> > ---
> 	
> [snip]
> 
> > -static inline void
> > -scmi_create_protocol_devices(struct device_node *np, struct scmi_info *info,
> > -			     int prot_id)
> > +	for (; rdev; rdev = rdev->next)
> > +		scmi_create_protocol_device(np, info, prot_id,
> > +					    rdev->id_table->name);
> > +}
> > +
> > +/**
> > + * scmi_request_protocol_device  - Helper to request a device
> > + *
> > + * @id_table: A protocol/name pair descriptor for the device to be created.
> > + *
> > + * This helper let an SCMI driver request specific devices identified by the
> > + * @id_table to be created for each active SCMI instance.
> > + *
> > + * The requested device name MUST NOT be already existent for any protocol;
> > + * at first the freshly requested @id_table is annotated in the IDR table
> > + * @scmi_requested_devices, then a matching device is created for each already
> > + * active SCMI instance. (if any)
> > + *
> > + * This way the requested device is created straight-away for all the already
> > + * initialized(probed) SCMI instances (handles) but it remains instead pending
> > + * for creation if the requesting SCMI driver is loaded before some instance
> > + * and related transports was available: when such late SCMI instance is probed
> > + * it will take care to scan the list of pending requested devices and create
> > + * those on its own (see @scmi_create_protocol_devices and its enclosing loop)
> > + *
> > + * Return: 0 on Success
> > + */
> > +int scmi_request_protocol_device(const struct scmi_device_id *id_table)
> >   {
> > -	int loop, cnt;
> > +	int ret = 0;
> > +	unsigned int id = 0;
> > +	struct scmi_requested_dev *rdev, *proto_rdev = NULL;
> > +	struct scmi_info *info;
> > -	for (loop = 0; loop < ARRAY_SIZE(devnames); loop++) {
> > -		if (devnames[loop].protocol_id != prot_id)
> > -			continue;
> > +	pr_debug("Requesting SCMI device (%s) for protocol %x\n",
> > +		 id_table->name, id_table->protocol_id);
> > -		for (cnt = 0; cnt < ARRAY_SIZE(devnames[loop].names); cnt++) {
> > -			const char *name = devnames[loop].names[cnt];
> > +	/*
> > +	 * Search for the matching protocol rdev list and then search
> > +	 * of any existent equally named device...fails if any duplicate found.
> > +	 */
> > +	mutex_lock(&scmi_requested_devices_mutex);
> > +	idr_for_each_entry(&scmi_requested_devices, rdev, id) {
> > +		if (rdev->id_table->protocol_id == id_table->protocol_id)
> > +			proto_rdev = rdev;
> > +		for (; rdev; rdev = rdev->next) {
> > +			if (!strcmp(rdev->id_table->name, id_table->name)) {
> > +				pr_err("Ignoring duplicate request [%d] %s\n",
> > +				       rdev->id_table->protocol_id,
> > +				       rdev->id_table->name);
> > +				ret = -EINVAL;
> > +				goto out;
> > +			}
> 	Shouldn't there be proto_rdev = rdev here as well ?
> 

No, because each IDR entry points to one or more linked rdev descriptors
for the same protocol: while scanning each list in the IDR table I'm
searching for the proto_rdev representing the head of that protocol list
(if any already exist) and also scan all the lists fully to check for
duplicates, in such a case we give up.
The IDR map containing list resembles a lot a Linux hash implementation
but I decided not to use it because it seemed cumbersome to use an
hash given most of the time each IDR entry will contain just one single
element and this lookup happens really very infrequently (just at driver
loading time)

> > +		}
> > +	}
> > +
> > +	/*
> > +	 * No duplicate found for requested id_table, so let's create a new
> > +	 * requested device entry for this new valid request.
> > +	 */
> > +	rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
> > +	if (!rdev) {
> > +		ret = -ENOMEM;
> > +		goto out;
> > +	}
> > +	rdev->id_table = id_table;
> > +
> > +	/*
> > +	 * Append the new requested device table descriptor to the head of the
> > +	 * related protocol chain, eventually creating such chain if not already
> > +	 * there.
> > +	 */
> > +	if (!proto_rdev) {
> > +		ret = idr_alloc(&scmi_requested_devices, (void *)rdev,
> > +				rdev->id_table->protocol_id,
> > +				rdev->id_table->protocol_id + 1, GFP_KERNEL);
> > +		if (ret != rdev->id_table->protocol_id) {
> > +			pr_err("Failed to save SCMI device - ret:%d\n", ret);
> > +			kfree(rdev);
> > +			ret = -EINVAL;
> > +			goto out;
> > +		}
> > +		ret = 0;
> > +	} else {
> > +		proto_rdev->next = rdev;
> > +	}
> > +
> > +	/*
> > +	 * Now effectively create and initialize the requested device for every
> > +	 * already initialized SCMI instance which has registered the requested
> > +	 * protocol as a valid active one: i.e. defined in DT and supported by
> > +	 * current platform FW.
> > +	 */
> > +	mutex_lock(&scmi_list_mutex);
> > +	list_for_each_entry(info, &scmi_list, node) {
> > +		struct device_node *child;
> > +
> > +		child = idr_find(&info->active_protocols,
> > +				 id_table->protocol_id);
> > +		if (child) {
> > +			struct scmi_device *sdev;
> > +
> > +			sdev = scmi_get_protocol_device(child, info,
> > +							id_table->protocol_id,
> > +							id_table->name);
> > +			/* Set handle if not already set (device existed) */
> > +			if (sdev && !sdev->handle)
> > +				sdev->handle = scmi_handle_get_from_info(info);
> > +		} else {
> > +			dev_err(info->dev,
> > +				"Failed. SCMI protocol %d not active.\n",
> > +				id_table->protocol_id);
> > +		}
> > +	}
> > +	mutex_unlock(&scmi_list_mutex);
> > +
> > +out:
> > +	mutex_unlock(&scmi_requested_devices_mutex);
> > +
> > +	return ret;
> > +}
> > +
> > +/**
> > + * scmi_unrequest_protocol_device  - Helper to unrequest a device
> > + *
> > + * @id_table: A protocol/name pair descriptor for the device to be unrequested.
> > + *
> > + * An helper to let an SCMI driver release its request about devices; note that
> > + * devices are created and initialized once the first SCMI driver request them
> > + * but they destroyed only on SCMI core unloading/unbinding.
> > + *
> > + * The current SCMI transport layer uses such devices as internal references and
> > + * as such they could be shared as same transport between multiple drivers so
> > + * that cannot be safely destroyed till the whole SCMI stack is removed.
> > + * (unless adding further burden of refcounting.)
> > + */
> > +void scmi_unrequest_protocol_device(const struct scmi_device_id *id_table)
> > +{
> > +	struct scmi_requested_dev *victim, *prev, *head;
> > +
> > +	pr_debug("Unrequesting SCMI device (%s) for protocol %x\n",
> > +		 id_table->name, id_table->protocol_id);
> > -			if (name)
> > -				scmi_create_protocol_device(np, info, prot_id,
> > -							    name);
> > +	head = idr_find(&scmi_requested_devices, id_table->protocol_id);
> > +	if (!head)
> > +		return;
> > +
> > +	/*
> > +	 * Scan the protocol list of requested device name searching
> > +	 * for the victim.
> > +	 */
> > +	victim = head;
> > +	for (prev = victim; victim; prev = victim, victim = victim->next)
> 
> 	The initial assignment for the for loop is wrong. With this when you break
> prev will be equal to victim. You want prev to be the one pointing to the
> victim. Or am I missing something?
> 

Yes prev is the one preceding the victim, if any, but if it was the head
I'll remove the head and not use at all the prev really.
I think is right as it is, it is the naming that is misleading, because
yes in the initial assignment prev = victim BUT victim = head, so if I bail
out immediately I'm really removing the head.
It would be clearer like

         prev = victim = head;
         for (; victim; prev = victim, victim = victim->next)
	 ...

But it's better that I review this whole loop in deep to simplify it; I
avoided using klist because seemed easier enough to handle a singly
linked list which most of the time is one element deep, buut maybe I
should just stick with well known and proven kists.

Thanks

Cristian

> 
> -- 
> Warm Regards
> Thara

WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: Thara Gopinath <thara.gopinath@linaro.org>
Cc: f.fainelli@gmail.com, vincent.guittot@linaro.org,
	sudeep.holla@arm.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, james.quinlan@broadcom.com,
	Jonathan.Cameron@Huawei.com, souvik.chakravarty@arm.com,
	etienne.carriere@linaro.org, lukasz.luba@arm.com
Subject: Re: [PATCH v4 37/37] firmware: arm_scmi: add dynamic scmi devices creation
Date: Fri, 8 Jan 2021 14:42:57 +0000	[thread overview]
Message-ID: <20210108144257.GD9138@e120937-lin> (raw)
In-Reply-To: <50434a02-0fe0-50f3-1529-51ab8a0cc1f3@linaro.org>

On Thu, Jan 07, 2021 at 09:28:07AM -0500, Thara Gopinath wrote:
> Hi Christian,
> 
> On 1/6/21 3:16 PM, 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>
> > ---
> 	
> [snip]
> 
> > -static inline void
> > -scmi_create_protocol_devices(struct device_node *np, struct scmi_info *info,
> > -			     int prot_id)
> > +	for (; rdev; rdev = rdev->next)
> > +		scmi_create_protocol_device(np, info, prot_id,
> > +					    rdev->id_table->name);
> > +}
> > +
> > +/**
> > + * scmi_request_protocol_device  - Helper to request a device
> > + *
> > + * @id_table: A protocol/name pair descriptor for the device to be created.
> > + *
> > + * This helper let an SCMI driver request specific devices identified by the
> > + * @id_table to be created for each active SCMI instance.
> > + *
> > + * The requested device name MUST NOT be already existent for any protocol;
> > + * at first the freshly requested @id_table is annotated in the IDR table
> > + * @scmi_requested_devices, then a matching device is created for each already
> > + * active SCMI instance. (if any)
> > + *
> > + * This way the requested device is created straight-away for all the already
> > + * initialized(probed) SCMI instances (handles) but it remains instead pending
> > + * for creation if the requesting SCMI driver is loaded before some instance
> > + * and related transports was available: when such late SCMI instance is probed
> > + * it will take care to scan the list of pending requested devices and create
> > + * those on its own (see @scmi_create_protocol_devices and its enclosing loop)
> > + *
> > + * Return: 0 on Success
> > + */
> > +int scmi_request_protocol_device(const struct scmi_device_id *id_table)
> >   {
> > -	int loop, cnt;
> > +	int ret = 0;
> > +	unsigned int id = 0;
> > +	struct scmi_requested_dev *rdev, *proto_rdev = NULL;
> > +	struct scmi_info *info;
> > -	for (loop = 0; loop < ARRAY_SIZE(devnames); loop++) {
> > -		if (devnames[loop].protocol_id != prot_id)
> > -			continue;
> > +	pr_debug("Requesting SCMI device (%s) for protocol %x\n",
> > +		 id_table->name, id_table->protocol_id);
> > -		for (cnt = 0; cnt < ARRAY_SIZE(devnames[loop].names); cnt++) {
> > -			const char *name = devnames[loop].names[cnt];
> > +	/*
> > +	 * Search for the matching protocol rdev list and then search
> > +	 * of any existent equally named device...fails if any duplicate found.
> > +	 */
> > +	mutex_lock(&scmi_requested_devices_mutex);
> > +	idr_for_each_entry(&scmi_requested_devices, rdev, id) {
> > +		if (rdev->id_table->protocol_id == id_table->protocol_id)
> > +			proto_rdev = rdev;
> > +		for (; rdev; rdev = rdev->next) {
> > +			if (!strcmp(rdev->id_table->name, id_table->name)) {
> > +				pr_err("Ignoring duplicate request [%d] %s\n",
> > +				       rdev->id_table->protocol_id,
> > +				       rdev->id_table->name);
> > +				ret = -EINVAL;
> > +				goto out;
> > +			}
> 	Shouldn't there be proto_rdev = rdev here as well ?
> 

No, because each IDR entry points to one or more linked rdev descriptors
for the same protocol: while scanning each list in the IDR table I'm
searching for the proto_rdev representing the head of that protocol list
(if any already exist) and also scan all the lists fully to check for
duplicates, in such a case we give up.
The IDR map containing list resembles a lot a Linux hash implementation
but I decided not to use it because it seemed cumbersome to use an
hash given most of the time each IDR entry will contain just one single
element and this lookup happens really very infrequently (just at driver
loading time)

> > +		}
> > +	}
> > +
> > +	/*
> > +	 * No duplicate found for requested id_table, so let's create a new
> > +	 * requested device entry for this new valid request.
> > +	 */
> > +	rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
> > +	if (!rdev) {
> > +		ret = -ENOMEM;
> > +		goto out;
> > +	}
> > +	rdev->id_table = id_table;
> > +
> > +	/*
> > +	 * Append the new requested device table descriptor to the head of the
> > +	 * related protocol chain, eventually creating such chain if not already
> > +	 * there.
> > +	 */
> > +	if (!proto_rdev) {
> > +		ret = idr_alloc(&scmi_requested_devices, (void *)rdev,
> > +				rdev->id_table->protocol_id,
> > +				rdev->id_table->protocol_id + 1, GFP_KERNEL);
> > +		if (ret != rdev->id_table->protocol_id) {
> > +			pr_err("Failed to save SCMI device - ret:%d\n", ret);
> > +			kfree(rdev);
> > +			ret = -EINVAL;
> > +			goto out;
> > +		}
> > +		ret = 0;
> > +	} else {
> > +		proto_rdev->next = rdev;
> > +	}
> > +
> > +	/*
> > +	 * Now effectively create and initialize the requested device for every
> > +	 * already initialized SCMI instance which has registered the requested
> > +	 * protocol as a valid active one: i.e. defined in DT and supported by
> > +	 * current platform FW.
> > +	 */
> > +	mutex_lock(&scmi_list_mutex);
> > +	list_for_each_entry(info, &scmi_list, node) {
> > +		struct device_node *child;
> > +
> > +		child = idr_find(&info->active_protocols,
> > +				 id_table->protocol_id);
> > +		if (child) {
> > +			struct scmi_device *sdev;
> > +
> > +			sdev = scmi_get_protocol_device(child, info,
> > +							id_table->protocol_id,
> > +							id_table->name);
> > +			/* Set handle if not already set (device existed) */
> > +			if (sdev && !sdev->handle)
> > +				sdev->handle = scmi_handle_get_from_info(info);
> > +		} else {
> > +			dev_err(info->dev,
> > +				"Failed. SCMI protocol %d not active.\n",
> > +				id_table->protocol_id);
> > +		}
> > +	}
> > +	mutex_unlock(&scmi_list_mutex);
> > +
> > +out:
> > +	mutex_unlock(&scmi_requested_devices_mutex);
> > +
> > +	return ret;
> > +}
> > +
> > +/**
> > + * scmi_unrequest_protocol_device  - Helper to unrequest a device
> > + *
> > + * @id_table: A protocol/name pair descriptor for the device to be unrequested.
> > + *
> > + * An helper to let an SCMI driver release its request about devices; note that
> > + * devices are created and initialized once the first SCMI driver request them
> > + * but they destroyed only on SCMI core unloading/unbinding.
> > + *
> > + * The current SCMI transport layer uses such devices as internal references and
> > + * as such they could be shared as same transport between multiple drivers so
> > + * that cannot be safely destroyed till the whole SCMI stack is removed.
> > + * (unless adding further burden of refcounting.)
> > + */
> > +void scmi_unrequest_protocol_device(const struct scmi_device_id *id_table)
> > +{
> > +	struct scmi_requested_dev *victim, *prev, *head;
> > +
> > +	pr_debug("Unrequesting SCMI device (%s) for protocol %x\n",
> > +		 id_table->name, id_table->protocol_id);
> > -			if (name)
> > -				scmi_create_protocol_device(np, info, prot_id,
> > -							    name);
> > +	head = idr_find(&scmi_requested_devices, id_table->protocol_id);
> > +	if (!head)
> > +		return;
> > +
> > +	/*
> > +	 * Scan the protocol list of requested device name searching
> > +	 * for the victim.
> > +	 */
> > +	victim = head;
> > +	for (prev = victim; victim; prev = victim, victim = victim->next)
> 
> 	The initial assignment for the for loop is wrong. With this when you break
> prev will be equal to victim. You want prev to be the one pointing to the
> victim. Or am I missing something?
> 

Yes prev is the one preceding the victim, if any, but if it was the head
I'll remove the head and not use at all the prev really.
I think is right as it is, it is the naming that is misleading, because
yes in the initial assignment prev = victim BUT victim = head, so if I bail
out immediately I'm really removing the head.
It would be clearer like

         prev = victim = head;
         for (; victim; prev = victim, victim = victim->next)
	 ...

But it's better that I review this whole loop in deep to simplify it; I
avoided using klist because seemed easier enough to handle a singly
linked list which most of the time is one element deep, buut maybe I
should just stick with well known and proven kists.

Thanks

Cristian

> 
> -- 
> Warm Regards
> Thara

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

  reply	other threads:[~2021-01-08 14:43 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 20:15 [PATCH v4 0/37] SCMI vendor protocols and modularization Cristian Marussi
2021-01-06 20:15 ` 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 [this message]
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=20210108144257.GD9138@e120937-lin \
    --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.