All of lore.kernel.org
 help / color / mirror / Atom feed
From: andy.shevchenko@gmail.com
To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Cc: "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Peng Fan <peng.fan@oss.nxp.com>,
	Michal Simek <michal.simek@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [RFC v2 2/3] pinctrl: Implementation of the generic scmi-pinctrl driver
Date: Fri, 5 May 2023 23:35:21 +0300	[thread overview]
Message-ID: <ZFVoiWnvq7UXSBBw@surfacebook> (raw)
In-Reply-To: <812ae71d017b115c55648dbf0a4c3502715b1955.1682513390.git.oleksii_moisieiev@epam.com>

Wed, Apr 26, 2023 at 01:26:37PM +0000, Oleksii Moisieiev kirjoitti:
> scmi-pinctrl driver implements pinctrl driver interface and using
> SCMI protocol to redirect messages from pinctrl subsystem SDK to
> SCP firmware, which does the changes in HW.
> 
> This setup expects SCP firmware (or similar system, such as ATF)
> to be installed on the platform, which implements pinctrl driver
> for the specific platform.
> 
> SCMI-Pinctrl driver should be configured from the device-tree and uses
> generic device-tree mappings for the configuration.

...

> +#include <linux/device.h>
> +#include <linux/err.h>

> +#include <linux/of.h>

I do not see any user of this header. Do you?

> +#include <linux/module.h>
> +#include <linux/seq_file.h>
> +
> +#include <linux/pinctrl/machine.h>
> +#include <linux/pinctrl/pinconf.h>
> +#include <linux/pinctrl/pinconf-generic.h>
> +#include <linux/pinctrl/pinctrl.h>
> +#include <linux/pinctrl/pinmux.h>

> +#include <linux/scmi_protocol.h>
> +#include <linux/slab.h>

Please, move these two to the upper group of the generic headers.

> +struct scmi_pinctrl_funcs {
> +	unsigned int num_groups;
> +	const char **groups;
> +};

Please, use struct pinfunction.

...

> +struct scmi_pinctrl {

> +	struct scmi_pinctrl_funcs *functions;
> +	unsigned int nr_functions;

> +	char **groups;
> +	unsigned int nr_groups;

I'm not sure what is the difference to what "functions" above represent.

> +};

...

> +static void pinctrl_scmi_pin_dbg_show(struct pinctrl_dev *pctldev,
> +				      struct seq_file *s,
> +				      unsigned int offset)
> +{
> +	seq_puts(s, DRV_NAME);
> +}

What is the usefulness of this method?

...

> +static int pinctrl_scmi_pinconf_group_get(struct pinctrl_dev *pctldev,
> +					  unsigned int _pin,
> +					  unsigned long *config)
> +{
> +	int ret;
> +	struct scmi_pinctrl *pmx;
> +	enum pin_config_param config_type;
> +	unsigned long config_value;
> +
> +	if (!pctldev)
> +		return -EINVAL;
> +
> +	pmx = pinctrl_dev_get_drvdata(pctldev);
> +
> +	if (!pmx || !pmx->ph || !config)
> +		return -EINVAL;
> +
> +	config_type = pinconf_to_config_param(*config);
> +
> +	ret = pinctrl_ops->get_config(pmx->ph, _pin, GROUP_TYPE,
> +				      config_type, (u32 *)&config_value);

Endianess issue. This is, while likely working code, still ugly.

> +	if (ret)
> +		return ret;
> +
> +	*config = pinconf_to_config_packed(config_type, config_value);
> +
> +	return 0;
> +}

...

> + err:

err_free.

> +	kfree(pmx->pins);
> +	pmx->nr_pins = 0;
> +
> +	return ret;

...

> +static const struct scmi_device_id scmi_id_table[] = {
> +	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },

> +	{ },

No comma for the terminator entry.

> +};

...

> +	pinctrl_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_PINCTRL,
> +						&ph);

Can be on one line.

> +	if (IS_ERR(pinctrl_ops))
> +		return PTR_ERR(pinctrl_ops);

...

> +	if (pmx->nr_functions) {
> +		pmx->functions =
> +			devm_kcalloc(&sdev->dev, pmx->nr_functions,
> +				     sizeof(*pmx->functions),
> +				     GFP_KERNEL);
> +		if (!pmx->functions) {
> +			ret = -ENOMEM;
> +			goto clean;

Interleaving devm_*() with non-devm_*() in such order is not a good idea.

> +		}
> +	}
> +
> +	if (pmx->nr_groups) {
> +		pmx->groups =
> +			devm_kcalloc(&sdev->dev, pmx->nr_groups,
> +				     sizeof(*pmx->groups),
> +				     GFP_KERNEL);
> +		if (!pmx->groups) {
> +			ret = -ENOMEM;
> +			goto clean;
> +		}
> +	}
> +
> +	return pinctrl_enable(pmx->pctldev);
> +
> +clean:

err_free:

> +	if (pmx) {
> +		kfree(pmx->functions);
> +		kfree(pmx->groups);

Ah, this is simply wrong.

> +	}
> +
> +	kfree(pmx);

-- 
With Best Regards,
Andy Shevchenko



WARNING: multiple messages have this Message-ID (diff)
From: andy.shevchenko@gmail.com
To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Cc: "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Peng Fan <peng.fan@oss.nxp.com>,
	Michal Simek <michal.simek@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [RFC v2 2/3] pinctrl: Implementation of the generic scmi-pinctrl driver
Date: Fri, 5 May 2023 23:35:21 +0300	[thread overview]
Message-ID: <ZFVoiWnvq7UXSBBw@surfacebook> (raw)
In-Reply-To: <812ae71d017b115c55648dbf0a4c3502715b1955.1682513390.git.oleksii_moisieiev@epam.com>

Wed, Apr 26, 2023 at 01:26:37PM +0000, Oleksii Moisieiev kirjoitti:
> scmi-pinctrl driver implements pinctrl driver interface and using
> SCMI protocol to redirect messages from pinctrl subsystem SDK to
> SCP firmware, which does the changes in HW.
> 
> This setup expects SCP firmware (or similar system, such as ATF)
> to be installed on the platform, which implements pinctrl driver
> for the specific platform.
> 
> SCMI-Pinctrl driver should be configured from the device-tree and uses
> generic device-tree mappings for the configuration.

...

> +#include <linux/device.h>
> +#include <linux/err.h>

> +#include <linux/of.h>

I do not see any user of this header. Do you?

> +#include <linux/module.h>
> +#include <linux/seq_file.h>
> +
> +#include <linux/pinctrl/machine.h>
> +#include <linux/pinctrl/pinconf.h>
> +#include <linux/pinctrl/pinconf-generic.h>
> +#include <linux/pinctrl/pinctrl.h>
> +#include <linux/pinctrl/pinmux.h>

> +#include <linux/scmi_protocol.h>
> +#include <linux/slab.h>

Please, move these two to the upper group of the generic headers.

> +struct scmi_pinctrl_funcs {
> +	unsigned int num_groups;
> +	const char **groups;
> +};

Please, use struct pinfunction.

...

> +struct scmi_pinctrl {

> +	struct scmi_pinctrl_funcs *functions;
> +	unsigned int nr_functions;

> +	char **groups;
> +	unsigned int nr_groups;

I'm not sure what is the difference to what "functions" above represent.

> +};

...

> +static void pinctrl_scmi_pin_dbg_show(struct pinctrl_dev *pctldev,
> +				      struct seq_file *s,
> +				      unsigned int offset)
> +{
> +	seq_puts(s, DRV_NAME);
> +}

What is the usefulness of this method?

...

> +static int pinctrl_scmi_pinconf_group_get(struct pinctrl_dev *pctldev,
> +					  unsigned int _pin,
> +					  unsigned long *config)
> +{
> +	int ret;
> +	struct scmi_pinctrl *pmx;
> +	enum pin_config_param config_type;
> +	unsigned long config_value;
> +
> +	if (!pctldev)
> +		return -EINVAL;
> +
> +	pmx = pinctrl_dev_get_drvdata(pctldev);
> +
> +	if (!pmx || !pmx->ph || !config)
> +		return -EINVAL;
> +
> +	config_type = pinconf_to_config_param(*config);
> +
> +	ret = pinctrl_ops->get_config(pmx->ph, _pin, GROUP_TYPE,
> +				      config_type, (u32 *)&config_value);

Endianess issue. This is, while likely working code, still ugly.

> +	if (ret)
> +		return ret;
> +
> +	*config = pinconf_to_config_packed(config_type, config_value);
> +
> +	return 0;
> +}

...

> + err:

err_free.

> +	kfree(pmx->pins);
> +	pmx->nr_pins = 0;
> +
> +	return ret;

...

> +static const struct scmi_device_id scmi_id_table[] = {
> +	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },

> +	{ },

No comma for the terminator entry.

> +};

...

> +	pinctrl_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_PINCTRL,
> +						&ph);

Can be on one line.

> +	if (IS_ERR(pinctrl_ops))
> +		return PTR_ERR(pinctrl_ops);

...

> +	if (pmx->nr_functions) {
> +		pmx->functions =
> +			devm_kcalloc(&sdev->dev, pmx->nr_functions,
> +				     sizeof(*pmx->functions),
> +				     GFP_KERNEL);
> +		if (!pmx->functions) {
> +			ret = -ENOMEM;
> +			goto clean;

Interleaving devm_*() with non-devm_*() in such order is not a good idea.

> +		}
> +	}
> +
> +	if (pmx->nr_groups) {
> +		pmx->groups =
> +			devm_kcalloc(&sdev->dev, pmx->nr_groups,
> +				     sizeof(*pmx->groups),
> +				     GFP_KERNEL);
> +		if (!pmx->groups) {
> +			ret = -ENOMEM;
> +			goto clean;
> +		}
> +	}
> +
> +	return pinctrl_enable(pmx->pctldev);
> +
> +clean:

err_free:

> +	if (pmx) {
> +		kfree(pmx->functions);
> +		kfree(pmx->groups);

Ah, this is simply wrong.

> +	}
> +
> +	kfree(pmx);

-- 
With Best Regards,
Andy Shevchenko



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

  parent reply	other threads:[~2023-05-05 20:35 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26 13:26 [RFC v2 0/2] Introducing generic SCMI pinctrl driver implementation Oleksii Moisieiev
2023-04-26 13:26 ` Oleksii Moisieiev
2023-04-26 13:26 ` [RFC v2 2/3] pinctrl: Implementation of the generic scmi-pinctrl driver Oleksii Moisieiev
2023-05-05 12:03   ` Linus Walleij
2023-05-05 12:03     ` Linus Walleij
2023-05-05 20:01   ` Cristian Marussi
2023-05-05 20:01     ` Cristian Marussi
2023-05-11 10:23     ` Oleksii Moisieiev
2023-05-05 20:35   ` andy.shevchenko [this message]
2023-05-05 20:35     ` andy.shevchenko
2023-05-11 13:15     ` Oleksii Moisieiev
2023-05-12  9:04       ` Cristian Marussi
2023-05-12 12:18         ` Oleksii Moisieiev
2023-05-12 13:11           ` Cristian Marussi
2023-04-26 13:26 ` [RFC v2 1/3] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Oleksii Moisieiev
2023-04-26 13:26   ` Oleksii Moisieiev
2023-04-26 16:20   ` kernel test robot
2023-05-05 19:52   ` Cristian Marussi
2023-05-05 19:52     ` Cristian Marussi
2023-05-05 20:10     ` [PATCH] [REVIEW][PINCTRL]: Misc Fixes and refactor Cristian Marussi
2023-05-05 20:10       ` Cristian Marussi
2023-05-05 21:20       ` kernel test robot
2023-05-05 21:20         ` kernel test robot
2023-05-09  9:46       ` kernel test robot
2023-05-05 20:14     ` [PATCH] firmware: arm_scmi: Add optional flags to extended names helper Cristian Marussi
2023-05-05 20:14       ` Cristian Marussi
2023-05-07 20:38     ` [RFC v2 1/3] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Cristian Marussi
2023-05-07 20:38       ` Cristian Marussi
2023-05-12  8:38     ` Oleksii Moisieiev
2023-05-12  8:55       ` Cristian Marussi
2023-05-12 12:31         ` Oleksii Moisieiev
2023-05-12 12:32           ` Michal Simek
2023-06-07  6:31             ` Oleksii Moisieiev
2023-06-07  6:31               ` Oleksii Moisieiev
2023-05-09  3:40   ` kernel test robot
2023-04-26 13:26 ` [RFC v2 3/3] dt-bindings: firmware: arm,scmi: Add support for pinctrl protocol Oleksii Moisieiev
2023-04-26 13:26   ` Oleksii Moisieiev
2023-04-27  7:07   ` Michal Simek
2023-04-27  7:07     ` Michal Simek
2023-04-27  7:19     ` Oleksii Moisieiev
2023-04-27  7:19       ` Oleksii Moisieiev
2023-04-28 10:06   ` Krzysztof Kozlowski
2023-04-28 10:06     ` Krzysztof Kozlowski

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=ZFVoiWnvq7UXSBBw@surfacebook \
    --to=andy.shevchenko@gmail.com \
    --cc=Oleksii_Moisieiev@epam.com \
    --cc=cristian.marussi@arm.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=peng.fan@oss.nxp.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 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.