All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan_Lynch@mentor.com (Nathan Lynch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors
Date: Fri, 28 Aug 2015 11:24:20 -0500	[thread overview]
Message-ID: <55E08B34.9080102@mentor.com> (raw)
In-Reply-To: <1440757911-9120-4-git-send-email-lee.jones@linaro.org>

On 08/28/2015 05:31 AM, Lee Jones wrote:
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>  	  It's safe to say n here if you're not interested in multimedia
>  	  offloading.
>  
> +config ST_REMOTEPROC
> +	tristate "ST remoteproc support"
> +	depends on ARCH_STI
> +	select REMOTEPROC
> +	help
> +	  Say y here to support ST's adjunct processors via the remote
> +	  processor framework.
> +	  This can be either built-in or a loadable module.
> +

The code uses reset_control_* APIs, so this should depend on
RESET_CONTROLLER, no?

> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.barre@st.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + */

OK, but:

> +MODULE_LICENSE("GPL v2");

These are not in agreement.  You want "GPL" for MODULE_LICENSE if you
intend v2 or later.


> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_rproc *st_rproc = rproc->priv;
> +	int ret, err = 0;
> +
> +	if (st_rproc->config->sw_reset) {
> +		ret = reset_control_assert(st_rproc->sw_reset);
> +		if (ret)
> +			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> +	}
> +
> +	if (st_rproc->config->pwr_reset) {
> +		err = reset_control_assert(st_rproc->pwr_reset);
> +		if (err)
> +			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> +	}
> +
> +	clk_disable(st_rproc->clk);
> +
> +	return ret ?: err;
> +}

Sorry, but I think this is a stylistically inadequate response to my
earlier comments.  At least name the status variables sw_ret and pwr_ret
or something.  And it looks like ret could be used uninitialized.

Also, do you want to unconditionally call clk_disable even if you've
encountered errors?


> +static int st_rproc_start(struct rproc *rproc)
> +{
> +	struct st_rproc *st_rproc = rproc->priv;
> +	int err;
> +
> +	regmap_update_bits(st_rproc->boot_base, st_rproc->boot_offset,
> +			   st_rproc->config->bootaddr_mask, rproc->bootaddr);
> +
> +	err = clk_enable(st_rproc->clk);
> +	if (err) {
> +		dev_err(&rproc->dev, "Failed to enable clock\n");
> +		return err;
> +	}
> +
> +	if (st_rproc->config->sw_reset) {
> +		err = reset_control_deassert(st_rproc->sw_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> +			return err;
> +		}
> +	}
> +
> +	if (st_rproc->config->pwr_reset) {
> +		err = reset_control_deassert(st_rproc->pwr_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> +			return err;
> +		}
> +	}
> +
> +	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +	return 0;
> +}

Does this want to unwind any of its operations if it encounters a failure?

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <Nathan_Lynch@mentor.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: ohad@wizery.com, devicetree@vger.kernel.org, kernel@stlinux.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Ludovic Barre <ludovic.barre@st.com>
Subject: Re: [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors
Date: Fri, 28 Aug 2015 11:24:20 -0500	[thread overview]
Message-ID: <55E08B34.9080102@mentor.com> (raw)
In-Reply-To: <1440757911-9120-4-git-send-email-lee.jones@linaro.org>

On 08/28/2015 05:31 AM, Lee Jones wrote:
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>  	  It's safe to say n here if you're not interested in multimedia
>  	  offloading.
>  
> +config ST_REMOTEPROC
> +	tristate "ST remoteproc support"
> +	depends on ARCH_STI
> +	select REMOTEPROC
> +	help
> +	  Say y here to support ST's adjunct processors via the remote
> +	  processor framework.
> +	  This can be either built-in or a loadable module.
> +

The code uses reset_control_* APIs, so this should depend on
RESET_CONTROLLER, no?

> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.barre@st.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + */

OK, but:

> +MODULE_LICENSE("GPL v2");

These are not in agreement.  You want "GPL" for MODULE_LICENSE if you
intend v2 or later.


> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_rproc *st_rproc = rproc->priv;
> +	int ret, err = 0;
> +
> +	if (st_rproc->config->sw_reset) {
> +		ret = reset_control_assert(st_rproc->sw_reset);
> +		if (ret)
> +			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> +	}
> +
> +	if (st_rproc->config->pwr_reset) {
> +		err = reset_control_assert(st_rproc->pwr_reset);
> +		if (err)
> +			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> +	}
> +
> +	clk_disable(st_rproc->clk);
> +
> +	return ret ?: err;
> +}

Sorry, but I think this is a stylistically inadequate response to my
earlier comments.  At least name the status variables sw_ret and pwr_ret
or something.  And it looks like ret could be used uninitialized.

Also, do you want to unconditionally call clk_disable even if you've
encountered errors?


> +static int st_rproc_start(struct rproc *rproc)
> +{
> +	struct st_rproc *st_rproc = rproc->priv;
> +	int err;
> +
> +	regmap_update_bits(st_rproc->boot_base, st_rproc->boot_offset,
> +			   st_rproc->config->bootaddr_mask, rproc->bootaddr);
> +
> +	err = clk_enable(st_rproc->clk);
> +	if (err) {
> +		dev_err(&rproc->dev, "Failed to enable clock\n");
> +		return err;
> +	}
> +
> +	if (st_rproc->config->sw_reset) {
> +		err = reset_control_deassert(st_rproc->sw_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> +			return err;
> +		}
> +	}
> +
> +	if (st_rproc->config->pwr_reset) {
> +		err = reset_control_deassert(st_rproc->pwr_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> +			return err;
> +		}
> +	}
> +
> +	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +	return 0;
> +}

Does this want to unwind any of its operations if it encounters a failure?

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <Nathan_Lynch@mentor.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <kernel@stlinux.com>,
	<ohad@wizery.com>, <devicetree@vger.kernel.org>,
	Ludovic Barre <ludovic.barre@st.com>
Subject: Re: [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors
Date: Fri, 28 Aug 2015 11:24:20 -0500	[thread overview]
Message-ID: <55E08B34.9080102@mentor.com> (raw)
In-Reply-To: <1440757911-9120-4-git-send-email-lee.jones@linaro.org>

On 08/28/2015 05:31 AM, Lee Jones wrote:
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>  	  It's safe to say n here if you're not interested in multimedia
>  	  offloading.
>  
> +config ST_REMOTEPROC
> +	tristate "ST remoteproc support"
> +	depends on ARCH_STI
> +	select REMOTEPROC
> +	help
> +	  Say y here to support ST's adjunct processors via the remote
> +	  processor framework.
> +	  This can be either built-in or a loadable module.
> +

The code uses reset_control_* APIs, so this should depend on
RESET_CONTROLLER, no?

> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.barre@st.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + */

OK, but:

> +MODULE_LICENSE("GPL v2");

These are not in agreement.  You want "GPL" for MODULE_LICENSE if you
intend v2 or later.


> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_rproc *st_rproc = rproc->priv;
> +	int ret, err = 0;
> +
> +	if (st_rproc->config->sw_reset) {
> +		ret = reset_control_assert(st_rproc->sw_reset);
> +		if (ret)
> +			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> +	}
> +
> +	if (st_rproc->config->pwr_reset) {
> +		err = reset_control_assert(st_rproc->pwr_reset);
> +		if (err)
> +			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> +	}
> +
> +	clk_disable(st_rproc->clk);
> +
> +	return ret ?: err;
> +}

Sorry, but I think this is a stylistically inadequate response to my
earlier comments.  At least name the status variables sw_ret and pwr_ret
or something.  And it looks like ret could be used uninitialized.

Also, do you want to unconditionally call clk_disable even if you've
encountered errors?


> +static int st_rproc_start(struct rproc *rproc)
> +{
> +	struct st_rproc *st_rproc = rproc->priv;
> +	int err;
> +
> +	regmap_update_bits(st_rproc->boot_base, st_rproc->boot_offset,
> +			   st_rproc->config->bootaddr_mask, rproc->bootaddr);
> +
> +	err = clk_enable(st_rproc->clk);
> +	if (err) {
> +		dev_err(&rproc->dev, "Failed to enable clock\n");
> +		return err;
> +	}
> +
> +	if (st_rproc->config->sw_reset) {
> +		err = reset_control_deassert(st_rproc->sw_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> +			return err;
> +		}
> +	}
> +
> +	if (st_rproc->config->pwr_reset) {
> +		err = reset_control_deassert(st_rproc->pwr_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> +			return err;
> +		}
> +	}
> +
> +	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +	return 0;
> +}

Does this want to unwind any of its operations if it encounters a failure?


  reply	other threads:[~2015-08-28 16:24 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 10:31 [PATCH v2 0/4] remoteproc: Add driver for STMicroelectronics platforms Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 1/4] ARM: STiH407: Add nodes for RemoteProc Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-09-01  8:28   ` [STLinux Kernel] " Peter Griffin
2015-09-01  8:28     ` Peter Griffin
2015-09-01  8:28     ` Peter Griffin
2015-09-01  9:11     ` Lee Jones
2015-09-01  9:11       ` Lee Jones
2015-09-01  9:11       ` Lee Jones
2015-09-01  9:17       ` Peter Griffin
2015-09-01  9:17         ` Peter Griffin
2015-09-01  9:17         ` Peter Griffin
2015-08-28 10:31 ` [PATCH v2 2/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-08-31 15:28   ` Rob Herring
2015-08-31 15:28     ` Rob Herring
2015-08-31 15:28     ` Rob Herring
2015-09-01 10:41     ` Lee Jones
2015-09-01 10:41       ` Lee Jones
2015-09-01 11:49       ` Rob Herring
2015-09-01 11:49         ` Rob Herring
2015-09-01 11:49         ` Rob Herring
2015-09-01  8:58   ` [STLinux Kernel] " Peter Griffin
2015-09-01  8:58     ` Peter Griffin
2015-09-01  9:14     ` Lee Jones
2015-09-01  9:14       ` Lee Jones
2015-09-01  9:14       ` Lee Jones
2015-09-01 12:54     ` Lee Jones
2015-09-01 12:54       ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-08-28 16:24   ` Nathan Lynch [this message]
2015-08-28 16:24     ` Nathan Lynch
2015-08-28 16:24     ` Nathan Lynch
2015-09-01  7:55     ` Lee Jones
2015-09-01  7:55       ` Lee Jones
2015-09-01  7:55       ` Lee Jones
2015-09-01  8:17       ` [STLinux Kernel] " Peter Griffin
2015-09-01  8:17         ` Peter Griffin
2015-09-01  9:12         ` Lee Jones
2015-09-01  9:12           ` Lee Jones
2015-09-01  9:12           ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-08-28 15:23   ` Nathan Lynch
2015-08-28 15:23     ` Nathan Lynch
2015-08-28 15:23     ` Nathan Lynch
2015-09-01  7:48     ` Lee Jones
2015-09-01  7:48       ` Lee Jones
2015-08-28 17:17   ` Florian Fainelli
2015-08-28 17:17     ` Florian Fainelli
2015-08-28 17:17     ` Florian Fainelli
2015-09-01  7:41     ` Lee Jones
2015-09-01  7:41       ` Lee Jones
2015-09-01  7:41       ` Lee Jones

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=55E08B34.9080102@mentor.com \
    --to=nathan_lynch@mentor.com \
    --cc=linux-arm-kernel@lists.infradead.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.