Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1640226 > unrolled thread

Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to function

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to  function Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-05-12 08:40 +0200
    Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to  function Marc Kleine-Budde <mkl@pengutronix.de> - 2017-05-15 16:00 +0200
      Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to  function Oliver Hartkopp <socketcan@hartkopp.net> - 2017-05-16 06:00 +0200
        Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to  function Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-05-16 10:10 +0200
          Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to  function Oliver Hartkopp <socketcan@hartkopp.net> - 2017-05-16 15:20 +0200

#1640226 — Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to function

Hi all,

On 05/05/2017 15:50, Quentin Schulz wrote:
> To avoid possible ECC/parity checksum errors when reading an
> uninitialized buffer, the entire Message RAM is initialized when probing
> the driver. This initialization is done in the same function reading the
> Device Tree properties.
> 
> This patch moves the RAM initialization to a separate function so it can
> be called separately from device initialization from Device Tree.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>

It's been a week since I sent this patch series. Any comments?

Thanks,
Quentin

> ---
> 
> v4:
>   - remove unused variables from m_can_of_parse_mram,
> 
>  drivers/net/can/m_can/m_can.c | 26 +++++++++++++++-----------
>  1 file changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index bf8fdaeb955e..5da1bdb202a3 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -1489,11 +1489,23 @@ static int register_m_can_dev(struct net_device *dev)
>  	return register_candev(dev);
>  }
>  
> +static void m_can_init_ram(struct m_can_priv *priv)
> +{
> +	int end, i, start;
> +
> +	/* initialize the entire Message RAM in use to avoid possible
> +	 * ECC/parity checksum errors when reading an uninitialized buffer
> +	 */
> +	start = priv->mcfg[MRAM_SIDF].off;
> +	end = priv->mcfg[MRAM_TXB].off +
> +		priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE;
> +	for (i = start; i < end; i += 4)
> +		writel(0x0, priv->mram_base + i);
> +}
> +
>  static void m_can_of_parse_mram(struct m_can_priv *priv,
>  				const u32 *mram_config_vals)
>  {
> -	int i, start, end;
> -
>  	priv->mcfg[MRAM_SIDF].off = mram_config_vals[0];
>  	priv->mcfg[MRAM_SIDF].num = mram_config_vals[1];
>  	priv->mcfg[MRAM_XIDF].off = priv->mcfg[MRAM_SIDF].off +
> @@ -1529,15 +1541,7 @@ static void m_can_of_parse_mram(struct m_can_priv *priv,
>  		priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num,
>  		priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num);
>  
> -	/* initialize the entire Message RAM in use to avoid possible
> -	 * ECC/parity checksum errors when reading an uninitialized buffer
> -	 */
> -	start = priv->mcfg[MRAM_SIDF].off;
> -	end = priv->mcfg[MRAM_TXB].off +
> -		priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE;
> -	for (i = start; i < end; i += 4)
> -		writel(0x0, priv->mram_base + i);
> -
> +	m_can_init_ram(priv);
>  }
>  
>  static int m_can_plat_probe(struct platform_device *pdev)
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [next] | [standalone]

#1641715

[Multipart message — attachments visible in raw view] — view raw

On 05/12/2017 08:37 AM, Quentin Schulz wrote:
> Hi all,
> 
> On 05/05/2017 15:50, Quentin Schulz wrote:
>> To avoid possible ECC/parity checksum errors when reading an
>> uninitialized buffer, the entire Message RAM is initialized when probing
>> the driver. This initialization is done in the same function reading the
>> Device Tree properties.
>>
>> This patch moves the RAM initialization to a separate function so it can
>> be called separately from device initialization from Device Tree.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> 
> It's been a week since I sent this patch series. Any comments?

Looks good, added to linux-can-next.

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   |

[toc] | [prev] | [next] | [standalone]

#1642196

On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:
> On 05/12/2017 08:37 AM, Quentin Schulz wrote:
>> Hi all,
>>
>> On 05/05/2017 15:50, Quentin Schulz wrote:
>>> To avoid possible ECC/parity checksum errors when reading an
>>> uninitialized buffer, the entire Message RAM is initialized when probing
>>> the driver. This initialization is done in the same function reading the
>>> Device Tree properties.
>>>
>>> This patch moves the RAM initialization to a separate function so it can
>>> be called separately from device initialization from Device Tree.
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>
>> It's been a week since I sent this patch series. Any comments?
>
> Looks good, added to linux-can-next.

Isn't this a fix for linux-can instead?

At least it would make no sense to me to have the upgraded M_CAN driver 
in Linux 4.12 without this fix.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#1642291

Hi,

On 15/05/2017 at 20:51:30 -0700, Oliver Hartkopp wrote:
> On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:
> > On 05/12/2017 08:37 AM, Quentin Schulz wrote:
> > > On 05/05/2017 15:50, Quentin Schulz wrote:
> > > > To avoid possible ECC/parity checksum errors when reading an
> > > > uninitialized buffer, the entire Message RAM is initialized when probing
> > > > the driver. This initialization is done in the same function reading the
> > > > Device Tree properties.
> > > > 
> > > > This patch moves the RAM initialization to a separate function so it can
> > > > be called separately from device initialization from Device Tree.
> > > > 
> > > > Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> > > 
> > > It's been a week since I sent this patch series. Any comments?
> > 
> > Looks good, added to linux-can-next.
> 
> Isn't this a fix for linux-can instead?
> 
> At least it would make no sense to me to have the upgraded M_CAN driver in
> Linux 4.12 without this fix.
> 

The related suspend mode on the sama5d2 is not present in v4.12 so I
think this can wait v4.13.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1642558

Hi Alexandre,

On 05/16/2017 01:00 AM, Alexandre Belloni wrote:
> Hi,
>
> On 15/05/2017 at 20:51:30 -0700, Oliver Hartkopp wrote:
>> On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:
>>> Looks good, added to linux-can-next.
>>
>> Isn't this a fix for linux-can instead?
>>
>> At least it would make no sense to me to have the upgraded M_CAN driver in
>> Linux 4.12 without this fix.
>>
>
> The related suspend mode on the sama5d2 is not present in v4.12 so I
> think this can wait v4.13.
>

Agreed!

Thanks for the explanation.

Regards,
Oliver

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web