linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julien Thierry <julien.thierry@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
	ALKML <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>
Cc: Roy Franz <roy.franz@cavium.com>,
	Harb Abdulhamid <harba@codeaurora.org>,
	Nishanth Menon <nm@ti.com>, Arnd Bergmann <arnd@arndb.de>,
	Loc Ho <lho@apm.com>, Alexey Klimov <alexey.klimov@arm.com>,
	Ryan Harkin <Ryan.Harkin@arm.com>,
	Jassi Brar <jassisinghbrar@gmail.com>
Subject: Re: [PATCH v2 09/18] firmware: arm_scmi: probe and initialise all the supported protocols
Date: Wed, 6 Sep 2017 10:41:35 +0100	[thread overview]
Message-ID: <bc52d57a-156b-cef0-7560-63a9ed7e78b5@arm.com> (raw)
In-Reply-To: <1501857104-11279-10-git-send-email-sudeep.holla@arm.com>



On 04/08/17 15:31, Sudeep Holla wrote:
> Now that we have basic support for all the protocols in the
> specification, let's probe them individually and initialise them.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>   drivers/firmware/arm_scmi/common.h |  5 +++
>   drivers/firmware/arm_scmi/driver.c | 80 +++++++++++++++++++++++++++++++++++++-
>   2 files changed, 84 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 7473dfcad4ee..d7c73a8d260b 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -118,4 +118,9 @@ int scmi_version_get(const struct scmi_handle *h, u8 protocol, u32 *version);
>   void scmi_setup_protocol_implemented(const struct scmi_handle *handle,
>   				     u8 *prot_imp);
>   
> +typedef int (*scmi_init_fn_t)(struct scmi_handle *);
>   int scmi_base_protocol_init(struct scmi_handle *h);
> +int scmi_perf_protocol_init(struct scmi_handle *h);
> +int scmi_sensors_protocol_init(struct scmi_handle *h);
> +int scmi_power_protocol_init(struct scmi_handle *h);
> +int scmi_clock_protocol_init(struct scmi_handle *h);
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 601d0d7210d9..6f31761043e2 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -157,6 +157,12 @@ struct scmi_shared_mem {
>   	u8 msg_payload[0];
>   };
>   
> +struct scmi_protocol_match {
> +	u8 protocol_id;
> +	scmi_init_fn_t fn;

Could we call this "init" or "prot_init"?

> +	char name[32];
> +};
> +
>   static int scmi_linux_errmap[] = {
>   	/* better than switch case as long as return value is continuous */
>   	0,			/* SCMI_SUCCESS */
> @@ -687,6 +693,41 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
>   	return 0;
>   }
>   
> +static const struct scmi_protocol_match scmi_protocols[] = {
> +	{
> +		.protocol_id = SCMI_PROTOCOL_PERF,
> +		.fn = scmi_perf_protocol_init,
> +		.name = "scmi-cpufreq",
> +	}, {
> +		.protocol_id = SCMI_PROTOCOL_CLOCK,
> +		.fn = scmi_clock_protocol_init,
> +		.name = "scmi-clocks",
> +	}, {
> +		.protocol_id = SCMI_PROTOCOL_POWER,
> +		.fn = scmi_power_protocol_init,
> +		.name = "scmi-power-domain",
> +	}, {
> +		.protocol_id = SCMI_PROTOCOL_SENSOR,
> +		.fn = scmi_sensors_protocol_init,
> +		.name = "scmi-hwmon",
> +	},
> +	{}
> +};
> +
> +static const struct scmi_protocol_match *scmi_protocol_match_get(u8 protocol_id)
> +{
> +	int i;
> +	const struct scmi_protocol_match *match = NULL, *loop = scmi_protocols;
> +
> +	for (i = 0; i < ARRAY_SIZE(scmi_protocols); i++, loop++)
> +		if (loop->protocol_id == protocol_id) {
> +			match = loop;
> +			break;
> +		}
> +
> +	return match;
> +}
> +

The "match" variable is not needed. We can just return "loop" in the if 
branch and return NULL at the end of the function. Unless we are 
following some coding standard that advises against that?

>   static int scmi_mailbox_check(struct device_node *np)
>   {
>   	struct of_phandle_args arg;
> @@ -778,7 +819,7 @@ static int scmi_probe(struct platform_device *pdev)
>   	const struct scmi_desc *desc;
>   	struct scmi_info *info;
>   	struct device *dev = &pdev->dev;
> -	struct device_node *np = dev->of_node;
> +	struct device_node *child, *np = dev->of_node;
>   
>   	/* Only mailbox method supported, check for the presence of one */
>   	if (scmi_mailbox_check(np)) {
> @@ -817,6 +858,43 @@ static int scmi_probe(struct platform_device *pdev)
>   		return ret;
>   	}
>   
> +	for_each_available_child_of_node(np, child) {
> +		int init_ret;
> +		u32 prot_id;
> +		const struct scmi_protocol_match *match;
> +
> +		if (of_property_read_u32(child, "reg", &prot_id))
> +			continue;
> +
> +		prot_id &= MSG_PROTOCOL_ID_MASK;
> +
> +		if (!scmi_is_protocol_implemented(handle, prot_id)) {
> +			dev_err(dev, "SCMI protocol %d not implemented\n",
> +				prot_id);
> +			continue;
> +		}
> +
> +		match = scmi_protocol_match_get(prot_id);
> +		if (match) {
> +			struct platform_device *cdev;
> +
> +			cdev = of_platform_device_create(child, match->name,
> +							 dev);
> +			if (!cdev) {
> +				dev_err(dev, "failed to create %s device\n",
> +					match->name);
> +				continue;
> +			}
> +
> +			init_ret = match->fn(handle);
> +			if (init_ret) {
> +				dev_err(dev, "SCMI protocol %d init error %d\n",
> +					prot_id, init_ret);
> +				of_platform_device_destroy(&cdev->dev, NULL);
> +			}
> +		}
> +	}
> +

For the code in the "if (match)" branch, would it be better to have an 
inline function "scmi_create_protocol_device" or something with a name 
that fits?

Also I was wondering, what is the difference between the protocol being 
implemented and finding the matching structure? Feels like there is a 
bit of redundancy. If the protocol is implemented but doesn't have a 
match structure does it just mean it doesn't need any specific 
initialization?

Thanks,

-- 
Julien Thierry

  reply	other threads:[~2017-09-06  9:41 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04 14:31 [PATCH v2 00/18] firmware: ARM System Control and Management Interface(SCMI) support Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 01/18] dt-bindings: mailbox: add support for mailbox client shared memory Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 02/18] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol Sudeep Holla
2017-08-10 19:28   ` Rob Herring
2017-08-11  9:36     ` Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 03/18] firmware: arm_scmi: add basic driver infrastructure for SCMI Sudeep Holla
2017-08-08  2:46   ` Jassi Brar
2017-08-08  9:29     ` Sudeep Holla
2017-08-08 11:27       ` Jassi Brar
2017-09-05 10:03   ` Julien Thierry
2017-09-05 10:26     ` Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 04/18] firmware: arm_scmi: add common infrastructure and support for base protocol Sudeep Holla
2017-09-05 13:39   ` Julien Thierry
2017-09-05 13:45     ` Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 05/18] firmware: arm_scmi: add initial support for performance protocol Sudeep Holla
2017-09-05 15:04   ` Julien Thierry
2017-09-05 15:56     ` Julien Thierry
2017-09-05 16:54       ` Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 06/18] firmware: arm_scmi: add initial support for clock protocol Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 07/18] firmware: arm_scmi: add initial support for power protocol Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 08/18] firmware: arm_scmi: add initial support for sensor protocol Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 09/18] firmware: arm_scmi: probe and initialise all the supported protocols Sudeep Holla
2017-09-06  9:41   ` Julien Thierry [this message]
2017-09-06 13:31     ` Sudeep Holla
2017-09-06 13:41       ` Julien Thierry
2017-08-04 14:31 ` [PATCH v2 10/18] firmware: arm_scmi: add support for polling based SCMI transfers Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 11/18] firmware: arm_scmi: add option for polling based performance domain operations Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 12/18] firmware: arm_scmi: refactor in preparation to support per-protocol channels Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 13/18] firmware: arm_scmi: add per-protocol channels support using idr objects Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 14/18] firmware: arm_scmi: add device power domain support using genpd Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 15/18] clk: add support for clocks provided by SCMI Sudeep Holla
2017-09-01  0:19   ` Stephen Boyd
2017-09-04 13:37     ` Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 16/18] hwmon: add support for sensors exported via ARM SCMI Sudeep Holla
2017-08-04 19:32   ` Guenter Roeck
2017-08-07 12:25     ` Sudeep Holla
2017-08-14 15:09       ` Sudeep Holla
2017-08-14 18:04         ` Guenter Roeck
2017-08-04 14:31 ` [PATCH v2 17/18] cpufreq: add support for CPU DVFS based on SCMI message protocol Sudeep Holla
2017-08-09  4:18   ` Viresh Kumar
2017-08-09  9:59     ` Sudeep Holla
2017-08-09 10:06       ` Viresh Kumar
2017-08-09 10:15         ` Sudeep Holla
2017-08-04 14:31 ` [PATCH v2 18/18] cpufreq: scmi: add support for fast frequency switching Sudeep Holla
2017-08-09  4:28   ` Viresh Kumar
2017-08-09 10:09     ` Sudeep Holla
2017-08-09 10:13       ` Viresh Kumar
2017-08-09 10:17         ` Sudeep Holla

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=bc52d57a-156b-cef0-7560-63a9ed7e78b5@arm.com \
    --to=julien.thierry@arm.com \
    --cc=Ryan.Harkin@arm.com \
    --cc=alexey.klimov@arm.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=harba@codeaurora.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=lho@apm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=roy.franz@cavium.com \
    --cc=sudeep.holla@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).