All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
	Markus Pargmann <mpa@pengutronix.de>,
	Benedikt Spranger <b.spranger@linutronix.de>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [patch 02/12] can: c_can: Fix hardware raminit function
Date: Tue, 18 Mar 2014 19:38:52 +0100	[thread overview]
Message-ID: <532892BC.7080406@pengutronix.de> (raw)
In-Reply-To: <20140318171126.720944558@linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 3851 bytes --]

On 03/18/2014 06:19 PM, Thomas Gleixner wrote:
> The function is broken in several ways:
> 
>     - The function does not wait for the init to complete.
>       That can take quite some microseconds.
> 
>     - No protection against being called for two chips at the same
>       time. SMP is such a new thing, right?
> 
> Clear the start and the init done bit unconditionally and wait for
> both bits to be clear.
> 
> In the enable path set the init bit and wait
> for the init done bit.
> 
> Add proper locking.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  drivers/net/can/c_can/c_can_platform.c |   48 ++++++++++++++++++++++++++-------
>  1 file changed, 39 insertions(+), 9 deletions(-)
> 
> Index: linux/drivers/net/can/c_can/c_can_platform.c
> ===================================================================
> --- linux.orig/drivers/net/can/c_can/c_can_platform.c
> +++ linux/drivers/net/can/c_can/c_can_platform.c
> @@ -37,8 +37,10 @@
>  
>  #include "c_can.h"
>  
> -#define CAN_RAMINIT_START_MASK(i)	(1 << (i))
> -
> +#define CAN_RAMINIT_START_MASK(i)	(0x001 << (i))
> +#define CAN_RAMINIT_DONE_MASK(i)	(0x100 << (i))
> +#define CAN_RAMINIT_ALL_MASK(i)		(0x101 << (i))
> +static DEFINE_SPINLOCK(raminit_lock);
>  /*
>   * 16-bit c_can registers can be arranged differently in the memory
>   * architecture of different implementations. For example: 16-bit
> @@ -69,16 +71,44 @@ static void c_can_plat_write_reg_aligned
>  	writew(val, priv->base + 2 * priv->regs[index]);
>  }
>  
> +static void c_can_hw_raminit_wait(const struct c_can_priv *priv, u32 mask,
> +				  u32 val)
> +{
> +	/* We look only at the bits of our instance. */
> +	val &= mask;
> +	while ((readl(priv->raminit_ctrlreg) & mask) != val)
> +		udelay(1);

Do we have to add a timeout here, or is it "safe" to have a potential
endless loop here? As you have probably tortured the hardware and driver
a lot (or have been tortured by them), I assume you would have added a
timeout check if you had seen a lockup here.

> +}
> +
>  static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
>  {
> -	u32 val;
> +	u32 mask = CAN_RAMINIT_ALL_MASK(priv->instance);
> +	u32 ctrl;
> +
> +	spin_lock(&raminit_lock);
>  
> -	val = readl(priv->raminit_ctrlreg);
> -	if (enable)
> -		val |= CAN_RAMINIT_START_MASK(priv->instance);
> -	else
> -		val &= ~CAN_RAMINIT_START_MASK(priv->instance);
> -	writel(val, priv->raminit_ctrlreg);
> +	ctrl = readl(priv->raminit_ctrlreg);
> +	/*
> +	 * We clear the done and start bit first. The start bit is
> +	 * looking at the 0 -> transition, but is not self clearing;
> +	 * And we clear the init done bit as well.
> +	 */

nitpick: In the driver/net tree multi line comments look different, the
text starts right after the /*. No need to resend, I'll adjust this
while applying the patch.

> +	ctrl &= ~CAN_RAMINIT_START_MASK(priv->instance);
> +	ctrl |= CAN_RAMINIT_DONE_MASK(priv->instance);
> +	writel(ctrl, priv->raminit_ctrlreg);
> +	ctrl &= ~CAN_RAMINIT_DONE_MASK(priv->instance);
> +	c_can_hw_raminit_wait(priv, ctrl, mask);
> +
> +	if (enable) {
> +		/*
> +		 * Set start bit and wait for the done bit.
> +		 */
> +		ctrl |= CAN_RAMINIT_START_MASK(priv->instance);
> +		writel(ctrl, priv->raminit_ctrlreg);
> +		ctrl |= CAN_RAMINIT_DONE_MASK(priv->instance);
> +		c_can_hw_raminit_wait(priv, ctrl, mask);
> +	}
> +	spin_unlock(&raminit_lock);
>  }
>  
>  static struct platform_device_id c_can_id_table[] = {

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

  reply	other threads:[~2014-03-18 18:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 17:19 [patch 00/12] can: c_can: Fix a series of serious bugs and improve the performance Thomas Gleixner
2014-03-18 17:19 ` [patch 01/12] can: c_can: Wait for CONTROL_INIT to be cleared Thomas Gleixner
2014-03-18 18:11   ` Marc Kleine-Budde
2014-03-18 18:19     ` Thomas Gleixner
2014-03-18 17:19 ` [patch 02/12] can: c_can: Fix hardware raminit function Thomas Gleixner
2014-03-18 18:38   ` Marc Kleine-Budde [this message]
2014-03-18 22:15     ` Thomas Gleixner
2014-03-19  6:37       ` Oliver Hartkopp
2014-03-19  9:22         ` Thomas Gleixner
2014-03-18 17:19 ` [patch 03/12] can: c_can: Make it SMP safe Thomas Gleixner
2014-03-18 18:46   ` Marc Kleine-Budde
2014-03-18 19:40     ` Thomas Gleixner
2014-03-18 17:19 ` [patch 05/12] can: c_can: Fix the lost message handling Thomas Gleixner
2014-03-18 17:19 ` [patch 04/12] can: c_can: Fix buffer ordering for real Thomas Gleixner
2014-03-18 17:19 ` [patch 06/12] can: c_can: Remove braindamaged EOB exit Thomas Gleixner
2014-03-18 17:19 ` [patch 07/12] can: c_can: Provide protection in the xmit path Thomas Gleixner
2014-03-18 17:19 ` [patch 08/12] can: c_can: Makethe code readable Thomas Gleixner
2014-03-18 17:37   ` Joe Perches
2014-03-18 18:23     ` Thomas Gleixner
2014-03-18 18:27     ` [patch 08/12 V2] " Thomas Gleixner
2014-03-18 19:20       ` Joe Perches
2014-03-18 17:19 ` [patch 09/12] can: c_can: Reduce register access for real Thomas Gleixner
2014-03-18 17:19 ` [patch 10/12] can: c_can: Store dlc private Thomas Gleixner
2014-03-18 17:19 ` [patch 11/12] can: c_can: Simplify TX interrupt cleanup Thomas Gleixner
2014-03-18 17:19 ` [patch 12/12] can: c_can: Avoid led toggling for every packet Thomas Gleixner
2014-03-18 20:18   ` can: c_can: Reduce interrupt load by 50% Thomas Gleixner
2014-03-18 20:35     ` Joe Perches
2014-03-18 20:43       ` Thomas Gleixner
2014-03-18 21:27         ` Joe Perches
2014-03-31 22:35 ` [patch 00/12] can: c_can: Fix a series of serious bugs and improve the performance Thomas Gleixner
2014-04-01  8:09   ` Marc Kleine-Budde
2014-04-01  9:07     ` Thomas Gleixner
2014-04-01  9:09       ` Marc Kleine-Budde
2014-04-01 21:29     ` Marc Kleine-Budde

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=532892BC.7080406@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=b.spranger@linutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpa@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wg@grandegger.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.